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(54) Title: ELECTRONIC PAYMENT METHOD FOR PURCHASE-RELATED TRANSACTIONS OVER A COMPUTER NETWORK 
(54>T1tre: DE^f S^^^^S^^^ D'EFFECTUER DES TRANSACTIONS UEES A L' ACHAT 
(57) Abstract 

A method using an open communication 
network (10) to which retailer server stations 
(20) and customer stations (30) are connected. 
According to the method, a retailer server station 
generates a payment slip for the planned purchase 
transaction between the retailer and a customer, 
which slip comprises data on the retailer, the 
customer, the purchased item or service and 
the price; the payment slip is transmitted over 
the network to a payment server station (40); 
the payment server automatically checks whether 
the payment of said price is authorised for the 
customer in question, by querying die client's 
personal account set up in the payment server 
for paying small amounts, or, in the case of 
larger amounts, by making a query over a banking 
network (50) separate from the computer network 

(10); if the payment is authorised, the payment server generates a cash voucher comprising at least 
and the cash voucher is transmitted to die retailer to enable the purchase to go ahead. 




30 

some of the data on die payment slip; 
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(57) Abrtgt 



Le precede utilise un rfseau dc communication ouvcrt (10) sur lequel sont connect* des postes serveurs de maichands (20) et des 
nostes clients (30) et comprend: Pelaboration par un poste serveur de marchand d'un ticket de piuement, concemant un achat envisatfentre 
rr^S c ^m clieXe^mportant des informatics relatives au marchand, au client, a 1'objet de 1'achat et ft son prw; la transnuss.on 
du SS pSenl v£ £ Sun poste serveur de paiement (40); la verification automatique par le serveur de payment s- ^e 
du prix est autorise pour le client concert, soit par interrogation d'un compte cl.ent propre au client, tenu par le *?™J'W'™ n *\« 
destint au paiement des petits montants. soit par interrogation sur un reseau bancaue (50) independant du ^ u ' rf ™^ e < 
les paiememsde montantoplus eleves; si la verification est positive, 1'elaboration par le serveur de paiement d'un bon de caisse comportant 
a? S Z partiTdes informations du ticket de paiement; et la transmission du bon de caisse au serveur de marchand afin d autonser la 



realisation de 1' achat. 
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Procede de paiement electronique permettant d'efiectuer des transactions liles 
a l'achat de biens sur un reseau informatique 

La prescnte invention concernc un procede de paiement 61ectronique 
5 permettant d'effectuer des transactions lides a l'achat de biens offerts par des 
marchands au moyen de services teiematiques via un reseau de telecommunication 
informatique ouvert sur lequel sont connectes des postes serveurs de marchands et 
des postes clients. 

Par r€seau informatique ouvert, on entend ici un reseau sur lequel des 
10 particuliers ou des entreprises peuvent Hbrcment se connecter a la condition de 
disposer d'une adresse, par exemple le reseau "Internet". Les biens concern6s sont 
des produits ou des services, dont la foumiture est realisee hors du reseau apres la 
conclusion de la transaction, ou des biens immateriels, tels que des informations, 
dont la foumiture peut etre rlalisee via le reseau infonnatique. 
15 Divers precedes de paiement electronique ont ete proposes, certains 

6tant deja operationnels. 

Plusieurs procedes sont fondes sur une nouvelle representation de la 
monnaie. II s'agit d'une representation electronique, quelquefois denommec "jeton" 
qui peut etre purement logiciclle ou partiellement materielle, par exemple avec une 
20 carte a puce. Ccs procedes impliquent la circulation de monnaie sur le reseau 
informatique, ce qui pose des problemes difficiles de security vis-a-vis de la 
creation de fausse monnaie. 

D'autres precedes connus de paiement electronique impliquent une 
relation directe avec une banque ou un reseau bancaire. Typiquernent, de tels 
25 procedes sont employes dans les rfscaux de carte de credit commc, par exemple, 
des procedes bien connus utilisant des terminaux points de vente relies a un circuit 
carte bancaire ainsi que des precedes utilisant des cheques eiectroniques avec une 
signature electronique pour Tauthentification de lacheteur. Cest une forme de 
lettre d'engagement 6mise par un acheteur, remise au vendeur et acceptee et 
30 reconnue par une banque. 

Les proc6d6s qui impliquent k un moment ou un autre de la transaction 
une relation avec le systeme bancaire traditionnel et la mise en oeuvre d'une 
transaction dans ce systeme presentent des inconvenients. Ainsi, les transactions 
dans le systeme bancaire ont un cout reel qui devient prohibitif lorsque le montant 
35 de l'achat est trfcs faible, par exemple un montant associe a la consultation d'une 
base de donnees. Or, les rtseaux informatiques sont bien adaptes a la vente de 
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biens dc faible valeur, principalemcnt dcs bicns d'infonnation, puisquc la Hvraison 
du bicn peut sc faire par lc r£seau lui-meme. En outre, l'acces a un reseau bancaiie 
ou un reseau de carte bancaire doit etre hautcment protege, ce qui exclut 
pratiquement la possibility dun acces a travers un reseau infonnatique ouvert, tel 
5 que le reseau "Internet" sur lequel dcs acheteurs potentiels peuvent se connecter. 

L'invention a pour but de fournir un procdde permettant d'eviter les 
inconv6nients dcs proc£des connus, en particulier un proc6d6 permettant, sans 
circulation de monnaie 61ectronique, de rfaliser de fa$on simple et fiabie des 
transactions liees a l'achat de biens sur un reseau infonnatique, et ce aussi bien 
10 pour des biens de prix eleve necessitant une autorisation par le systeme bancaire 
traditionnel, que pour des biens de faible ou tres faible prix. 

Ce but est atteint grace a un procede du type defini en tete de la 
presente description et comportant, confonnement a l'invention, les 6tapes de : 

- elaboration par un poste serveur de marchand connect^ au r6seau 
15 d'une demandc d'autorisation de transaction, ou "ticket de paiement", concernant 

un achat envisage entre lc marchand et un client, et comportant des informations 
relatives au marchand, au client, a 1'objet de l'achat et a son prix, 

- transmission du ticket de paiement via le reseau infonnatique a un 
poste serveur dc paiement distinct des postes clients et serveurs de marchands, 

20 - verification automatique par le serveur de paiement si le paiement du 

prix est autorise pour le client concern*, la verification etant effectude, scion le 
montant du prix a payer, soit par interrogation d'un comptc propre au client, tcnu 
par le serveur de paiement, et destine au paiement des pctits montants, soit par 
interrogation sur un reseau bancaire ind6pendant du rdscau infonnatique, pour les 

25 paiements de montants plus 61ev6s, 

- si la verification est positive, elaboration par le serveur de paiement 
d'une autorisation de transaction ou bon de caisse comportant au moins une partie 
des informations du ticket de paiement, et 

- transmission du bon de caisse au serveur de marchand via le r6scau 
30 infonnatique, afin d'autoriser la realisation de l'achat. 

Ainsi, le procede selon Tinvention est remarquable en ce qu f il 
n f implique ni la creation de monnaie eiectronique, ni la circulation de monnaie 
eiectronique sur ie reseau infonnatique. 

La gestion des transactions est effectuee par un serveur de paiement 
35 qui seul peut acceder a un reseau bancaire ou un reseau de carte bancaire, et qui 
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gere des comptcs clients non bancaires sur lesquels des transactions de faiblcs 
montants peuvent etre effectuecs. 

Le serveur de paiement gere egalement des comptes marchands non 
bancaires utilises pour les transactions de faibles montants. Ainsi, lorsqu'un bon de 
caisse est transmis apres verification par interrogation d'un compte client tenu par 
le serveur de paiement, le montant de 1'achat est debits du compte client ct cr6dit6 
sur un compte marchand propre au marchand conceme et tenu par le serveur de 
paiement, ce qui n'entraine pas des couts de traitement Aleves. 

Chaque client dispose d'unc identic qui lui est propre pour pouvoir 
utiliser le procede de paiement. II doit egalement disposer d un compte bancaire 
reel, de preference un compte utilisable au moyen du systeme traditionnel des 
cartes bancaires. La verification par le serveur de paiement peut comprendre une 
phase prealable de validation de l'identite du client a partir du contemi du ticket de 
paiement. La validation de l'identite est une operation prealable a l'acces eventuel 
au compte du client, si le montant de 1'achat est faible, et/ou a l'acces au reseau 
bancaire si le montant est plus 6lev6. Le serveur de paiement comporte de 
preference des moyens, par exemple une base de donnees, pennettant de 
memoriscr les relations entre les identites des clients utilisees pour les transactions 
sur le reseau informatiquc et des identites bancaires (num6ros de comptes 
bancaires ou numeros de caites de credit) utilisees pour les transactions sur le 
reseau bancaire. On peut eviter de la sortc la circulation d'identites bancaires sur le 
reseau infonnatique. 

Un mode de realisation de l'invention sera maintenant decrit a titrc 
indicarif , mais non limitatif, en reference aux dessins annexes sur lesquels : 

- la figure 1 est une vue generate ties schematique d'un systeme de 
paiement electronique conforme a l'invention ; 

- la figure 2 est une representation sous forme d'un schema bloc d'un 
serveur de paiement du systeme de la figure 1 ; 

- la figure 3 illustre le deroulement des operations relatives a un achat 
30 au moyen du systeme de la figure 1 ; ct 

-les figures 4A a 4C sont des organigrammes montrant ties 
schematiquement les operations effectuees par le serveur de paiement. 

Sur la figure 1 est represent* de facon trcs schematique un reseau de 
telecommunication infonnatique 10 sur lequel sont connected des postes serveurs 
35 de marchands 20, des postes clients 30 et au moins un poste serveur de paiement 



20 



25 



40. 
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Le reseau infoimatique 10 est un reseau ouvcrt ou public, par cxemplc 

le reseau denomme "Internet". 

Les scrveurs de marchands 20 sont des unites tellcs que celles 
couramment utilisees pour des serveurs telematiques connectes sur "Internet", par 
5 exemple des unites organisees autour de machines "Unix" multiprocesseurs. 

Les postes clients 30 sont essentiellement des micro-ordinateurs qui 
sont munis de moyens de connexion au reseau "Internet" 10, par exemple sous 
forme d'intcrface "Web". Les serveurs de marchands 20 et de postes clients 30 
utilisent par exemple des logiciels connus sous la denomination "World Wide 
10 Web" (WWW) utilisant le protocole HTTP. 

Le serveur de paiement 40, montre avec plus de details sur la figure 2, 
comprend des unites frontalc et dorsale respectivement 41 et 42 connectecs toutes 
les deux au reseau "Internet" 10. L*unit6 frontalc 41 a une architecture semblable a 
cclle d'un serveur classique connecte sur un reseau tel qu^Internet"". L'unite 
15 dorsale 42 comporte une unite de traitement 43 a un ou plusieurs processeurs, une 
base de donnees 44 comportant des informations relatives aux marchands et clients 
abonnes au systeme de paiement, un registre de transactions 45, une unit6 46 
d'intcrface avec un reseau bancaire ou un reseau de carte bancaire 50, et un bus de 
communication 47 ou autre liaison similaire pcrmettant de relier entre eux les 
20 differents constituants de l'unit6 dorsale 42. Une liaison securisee 48 pennet une 
communication bidirectionnelle entre l'unitd frontalc 41 et l'unite de traitement 43. 
La communication avec lc reseau informatique 10 est controlee par l'unite frontale 
41 tandis que la gestion de la base de donnees 44 ainsi que le controle de la 
communication avec le reseau bancaire 50 sont assures par l'unite dorsale 42. 
25 La base de donnees 44 contient des informations relatives aux clients 

et aux marchands abonnes au systeme de paiement. Pour chaque client, la base de 
donnees 44 contient I'identitd systeme du client ("CId"), identic recue lore de 
l'abonnement au systeme, un compte de client ou porte monnaie electronique 
("PME") destine au paiement de faibles montants, une identite bancaire telle que 
30 numero de compte bancaire reel ou numero de carte de credit ainsi 
qu'cventuellement une clef d'acccs ou mot de passe propre au client. Pour chaque 
maichand, la base de donnees 44 contient i'identit* systeme du marchand ("Mid"), 
identite recue lors dc l'abonnement au systeme, un compte de marchand, ou tiroir- 
caisse electronique ("TCE") destine a l'encaissement des faibles montants et une 
35 identity bancaire telle que numero de compte bancaire reel. 
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La figure 3 illustre schematiquement les differentes 6tapes d'une 
transaction portant sur un achat d'un bicn par un client abonne a un marchand 
abonne. II peut s'agir d'un bien materiel dont ia livraison au client sera e£fcctu£e 
r6ellement apres conclusion de la transaction ou dun bien immateriel (tel que de 
5 ('information) qui peut etre foumie au client par le reseau informatique des le 
paiement llectronique effectue. 

m Consultation par le Hii»nt 

Par connexion sur le rfseau "Internet" 10, un client peut consulter en 
ligne le catalogue ou la "vitrine" d'un marchand quelconque par acces au serveur 
10 20 du marchand et par visualisation sur t'ecran du poste client 30 des biens ou 
services du marchand. Sur presentation de i'identite CId du client, le serveur du 
marchand peut presenter au client des conditions financieres particulicres (par 
exemple une remise) applicables a la transaction eventuelle. 
(2\ Demande d'achat 

15 Le choix du client £tant arrete sur un bien O, il est transmis au serveur 

du marchand sous forme d'un message contenant une identite Old du bien et 
I'identite CId du client. Lorsque cela est nccessaire, par exemple pour la livraison 
ulterieure du bien choisi, des informations compldmentaircs (par exemple une 
adresse et un horaire de livraison pr6ftr6). Cela peut etre realis6 de fagon 

20 commode en utilisant un formulaire electronique envoye sur le reseau et destine a 
etre rempli par le client. 

Dans le cas ou l'achat envisage represente un montant 61ev6 ou est 
soumis a des conditions legates, une authentification prealable du client peut etre 
soubaitee. Commc on le verra en detail plus loin 1'authentification d'un client est 

25 cffectu6e par le serveur de paiement 40. Aussi, une demande d'authentification 
provenant d'un marchand est 6mise avantageusement sous la forme d'un ticket de 
paiement de valeur nulle qui est transmis au serveur de paiement par le rdseau 
informatique via le poste client et, en cas d'authentification positive, provoquc le 
retour d'un bon de caisse du serveur de paiement au serveur marchand, toujours via 

30 le poste client. Les procedures d'&abiissement d'un ticket de paiement et de renvoi 
d'un bon de caisse sont ddcrites plus en detail ci-aprfcs. 

La demande d'achat 6mise par le client peut porter sur un seul bien ou 
sur plusieurs biens k fournir de fagon groupie : "achat panicr". 
(3) Elaboration de la demande de paiement 

35 En r6ponse a une demande d'achat, le serveur marchand 61abore une 

demande de paiement qui peut comprendre les informations suivantcs : 
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- Identity du marchand, ("Mid"); 

- Description du bicn commande, ou dc chacun des biens du panier, cn 

cas d'achats groupes; 

- Type de transaction (simple ou panier); 
5 - Identite du client, ("CId"); 

- Identity du bien ou de l'ensemble des biens du panier, ("Old"); 

- Prix de I'objet, ("Oid H ); 

- TVA (si applicable); 

- Date et heure de remission du ticket de paiement (horodatage par le 

10 scrveur marchand); 

- Duree de validit6 du ticket de paiement; 

- Numero de serie dans le registre des ventes du marchand (notamment 
dans le cas ou la transaction a comporte une etape prealable dauthentification). 

L'ensemble des informations ci-dessus est encodee dans une chaine 
15 doctets qui constitue la chaine opaque dun tidket de paiement (ou URL de 
commande de bien, URL etant les initiales de "Uniform Resource Locator" ou 
Localisateur de Ressource Uniforme utilise dans les logiciels WWW avec 
protocole HTTP), comme suit: 

URL http : < SP> < descriptif de la commando , 
20 oil SP est l'adresse "Internet" du serveur de paiement. Le ticket de paiement est 
adresse au poste client. U est complete par deux "ancres" logiques qui permcttent 
au client soit de l'annuler, soit de le confirmer. 

(d\ Ftivoi de l' ftfdre dc paiement 

L'ordre de paiement est transmis au seiveur de paiement simplement 
25 par validation par ie client dc I'URL de demande dc paiement. On comprendra 
bien que le ticket de paiement ne fait alors que transiter par le poste client. 
{*} f mission du bon de caisse 

Sur rdception d'un ordre de paiement, le serveur de paiement 40 le 
decode et procfcde a Tauthentification du client et recherche si le paiement peut etre 
30 autorise avant de retoumcr un bon de caisse ou un refus de paiement. 

Les operations dauthentification de client et dautorisation de paiement 
seront decrites plus loin en d6tail en reference a la figure 4. 

Lorsque les verifications effectuees ne permcttent pas dautoriscr le 
paiement, une notification de refus motivee est adrcss6c au client par le serveur de 
35 paiement (indiquant, par exemple, compte insuffisamment approvisionne, 
depassemcnt dun seuil autoris6 pour le client, ...) 
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Loisquc les verifications effectuees permettent d'autoriser 1c paiement, 
lcs informations contenues dans le ticket de paiement sont completees avec un 
numero de serie dans le rcgistre des transactions 45, une estampille horaire, une 
duree de validitf (typiquement quelques dizaines de secondes) et le sceau du 
5 serveur de paiement constituant une information de certification. L'ensemble de 
ces informations, Iventuellement aprfes signature num6rique par l'utilisation de la 
partie de clef priv6e d'un systeme de chiffrement a clef priv£e/clef publique du 
serveur de paiement (ce qui garantit la validite et Tintigrite de l'autorisation de 
paiement), est encode dans une chaine d'octets qui constitue la chaine opaque d'un 
10 bon de caisse ou URL de li vraison : 

URL http : <M> <descriptif du bon de caisse> , 
ou <M> est l'adresse "Internet" du marchand. 

(6) Demande de Hvraisnn 

Le bon de caisse est transmis au serveur du marchand via le poste 
15 client. Ceci peut etre effectue automatiquement par le logiciel implante au poste 
client en utilisant la possibility de re-routage des URL bien connue de 1'homme du 
metier. Avant d'autoriser la livraison du bien, le serveur du marchand op&re un 
decodage et une verification du bon de caisse rc$u. Cette verification consiste a 
utiliser la clef privgc eventuelle du serveur de paiement, a verifier que la durce de 
20 validite n'est pas ecoulee, et a rapprocher le contenu du bon de caisse avec celui de 
la demande de paiement. 

(7) Livraison du frfcn 

Lorsque le bon de caisse est valide par le serveur du marchand, celui- 
ci peut effectuer la livraison directe sur le poste client, dans le cas de bien 
25 d'information, ou adresse au poste client un document pennettant le retrait du bien 
et prgcisant notamment le lieu de livraison et le nom du recipiendaire. 

On notera que, dans le cas d'un achat group6 (panier), il y a creation 
par le serveur du marchand d'un objet avec affectation d ! une identity unique. Cet 
objet est la liste des URL de chacun des biens du panier. Cest cet objet qui est 
30 indique dans 1TJRL de commande de bien et qui pennettra d enregistrer le d6tail 
des biens achet6s dans le rcgistre de transaction du serveur de paiement. 

Les figures 4A a 4C montrent les op6rations effectu6es par le serveur 
de paiement 40 en n6ponse a la reception d f un ordre de paiement. 

Dans l*unit£ frontale 41 (figure 4A), Tordre de paiement est d6cod£ 
35 (6tape 61) et sa validity est examinde (test 62) notamment du point de vue de la 
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durcc de validite. Si lc rcsultat dc l'examen est ncgatif, unc notification dc rcfus est 
envoyee au postc client (etape 63). 

Si le resultat dc l'examen est positif, il est precede ensuite a une 
authentification du client (etape 64), le detail de cette operation etant decrit plus 

5 loin en reference a la figure 4C. Si l'authentification est negative (test 65), une 
notification de refus est envoyee au client (etape 63). Si elle est positive, l'ordre de 
paiement (6ventuellement limite a l'identite CId du client, a l'identit6 Mid du 
marchand, et au prix) est transmis via la liaison 68 a l'unite dorsale 42 du serveur 
de paiement represcnte sur la figure 2 (etape 66). La liaison 48 est une liaison 

10 securisee interdisant l'acces a l'unite dorsale a toute personne se connectant sur le 
reseau 10. 

L'unite frontale 41 attend alors que l'unite dorsale decide d'autoriser ou 
non le paiement (etape 67). Si le paiement n'est pas autorise, (test 68), unc 
notification de refus est envoyee au poste client (etape 63). Si le paiement est 
15 autorise, "un bon de" ca£se est eiabore {etope '69), mili^nt-les reformations 
enregistrces a l'dtape 62. Le bon de caisse est enregistre dans une memoire de 
l'unit6 frontale 41 (6tape 70) et est adresse au serveur du marchand via le poste 
client (fitape 71). 

Au niveau de l'unite dorsale 42 (figure 4B) du serveur de paiement, a la 
20 reception dun ordre de paiement authentifie, il est examine si celui-ci doit etre 
autorise a partir du compte client PME via lc reseau bancaire 50. A cet effet, le 
prix est compare a un seuil minimum (test 72). Ce seuil est par exemple de 
quclques dizaines de francs. 

Si lc seuil est depasse, une demande pour effectucr l'operation de 
25 paiement est lancee sur le reseau bancaire (etape 73) en utilisant l'identite bancaire 
correspondent a l'identite CId du client, telle qu'clle ressort de la consultation de la 
base de donnees 44. A la reception de la reponse positive ou negative (etape 74), 
celle-ci est transmise a l'unite frontale 41 (etape 75). 

Si le seuil n'est pas depasse, le paiement peut etre effectue a partir du 

30 compte PME du client. 

A cet effet, il est examine si le compte est suffisamment approvisionn6 
(test 76). Dans la negative, un refus d'autorisation de paiement, e'est-a-dire une 
reponse negative, est renvoyee a l'unite frontale (etape 75). Dans l'affirmative, le 
compte PME du client est debite du prix et le compte TCE de marchand 

35 correspondent a l'identite Mid est credite du meme montant (etape 77), la 
transaction est inscrite dans le registre des transactions 45 (etape 78) et 
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l'autorisation de paicment, c'est-a-dire une reponse positive est transmise a l'unite 
frontale 41 avec Indication du num6ro de serie de l'inscription dans le rcgistrc de 
transactions (etape 75). 

La procedure d'authentiflcation dans lc serveur de paiement (figure 
4Q, a l'etape 64 de la figure 4A, comprend I'envoi au poste client, de preference 
dans une forme securisee (chiffree), d'une demande de cl6 d'acces, ou mot de passe 
(6tape 641). A la reception securisee de la cie d'acces (Ctape 642), une comparaison 
est effectuee avec une information correspondante contenue dans la base de 
donnees 44 (test 643). 

Si la comparaison est negative, et qu'un nombre maximum de 
tentatives infructueuses n'a pas 6te atteint (test 644), on retoume a r6tape 641. Si ce 
nombre maximum est atteint, l'absence d'authentiflcation est constatee, une alerte 
est produite (etape 645) et une reponse negative est envoyee au poste client (6tape 
646). L'alerte peut consister en une annulation du compte PME ou en une 
15 surveillance de celui-ci afin de detcctcr de nouvelles tentatives d'utilisation. Si le 
test a l'etape 643 est positif, l'authentification est enregistrce (etapc 647) et une 
reponse positive est eiaboree (etape 648). 

Des techniques de chiffrement pennettant la transmission securisee 
d'informations numeriques sur rescau informatique, notamment pour la demande 
20 d envoi de cie d'acces et l'cnvoi de celle-ci, sont bien connues. 

La procedure d'authentiflcation decrit ici permet d'effectuer une 
authentification prealable d un client dans le cas ou celle-ci est necessaire avant 
retablissement d'une demande de paiement par le serveur du marchand. Pour cette 
authentification, il suffit alors en effet de creer un ticket de paiement dans lequel le 
25 prix indiquc est nul, comme indique plus haut. 

L enregistrement des bons de caisse dans l'unite frontale permet aux 
clients et aux marchands de procetler a des contrdles et d'en obtenir eventueUement 
des copies. L'enregistrement des transactions dans l'unite dorsale permet d'en 
conscrver une trace en cas, par exemple, de contestation cntre un client et un 
30 marchand. 

Les comptes clients PME gcres par le serveur de paicment ont en 
principe un montant de solde plafonne et, selon le mode de realisation prtfcnf de 
Tinvention, ils ne sont pas n£mun6res (le systeme de paiement se trouvant en 
dehors du monde bancaire). Un reapprovisionncmcnt de son compte PME par un 
35 client peut etre effectue a partir de son compte bancaire, par ordre donne a son 
etablissement bancaire. 
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Lcs comptes marchands TCE geres par lc serveur dc paicment sont 
associes a des comptes bancaires reels des marchands dans lesquels ils sont vides 
par exemple quotidiennemcnt. 

Bien que Ton ait decrit ci-avant un mode de mise en oeuvre d'un 

5 precede selon l'invention dans un cnvironnement "Internet- et avec des logiciels 
WWW utilisant le protocole HTTP, 1'homme de Tart comprcndra aisement que le 
precede peut ctrc mis en oeuvre avec un reseau informatique autre qu m Internet" ou 
encore avec des logiciels serveur marchand et client n'utilisant pas le protocole 
HTTP de WWW. En outre des precedes d'authentification securisfe mettant en jeu 

10 des dispositife matcriels tels que lecteur de carte a puce ou moyen de 
reconnaissance d'empreinte vocale pourront etre prevus a la place de clefs d'acefcs. 
Ces dernieres et d'autre modifications qui viendront a Tesprit du Thomme du metier 
sont comprises dans la philosophic et la portee de la presente invention. 
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REVENDICATIONS 

1. Proc6d6 dc paiement elcctronique pour des transactions liees a l'achat 

dc bicns offcrts par des marchands a dcs clients via un r6seau infonnatique ouvert 
sur lequel sont connectes des postes serveurs de marchands et dcs postes clients, 
5 caracterise par les etapes de : 

- Elaboration par un poste serveur de marchand connects au rcseau 
d'une demande d'autorisation de transaction, ou ticket de paiement, concernant un 
achat envisage entre le marchand et un client, et comportant des informations 
relatives au marchand, au client, a l'objet de l'achat et a son prix, 

10 " transmission du ticket de paiement via le r6seau infonnatique a un 

serveur de paiement distinct des postes clients et serveurs de marchands, 

- verification automatique par le serveur de paiement si le paiement du 
prix est autorise pour le client concerne, la verification £tant effectuee, selon le 
montant du prix a payer, soit par interrogation d'un compte client propre au client, 

15 tenu par le serveur de paiement, et destine au paiement des petits montants, soit par 
interrogation sur un reseau bancaire independant du rcseau infonnatique, pour les 
paiements de montants plus 61ev6s, 

- si la verification est positive, Elaboration par le serveur de paiement 
d'une autorisation de transaction ou bon de caisse comportant au moins une partie 

20 des informations du ticket dc paiement, et 

- transmission du bon dc caisse au serveur de marchand via le rcseau 
infonnatique, afin d'autoriser la realisation de l'achat. 

2. Proc6d6 selon la revendication 1, caracterise en ce que lorsqu'un bon 
de caisse est transmis aprfes verification par interrogation d un compte client tenu 

25 par le serveur de paiement, le montant de l'achat est d6bit6 du compte client et 
erudite sur un compte marchand propre au marchand concerne ct tenu par le 
serveur de paiement. 

3. Precede selon Tune quelconque des revendications 1 et 2, caracterise 
en ce que la verification par le serveur de paiement comprend une phase prEalable 

30 d'authentification du client. 

4. Precede selon la revendication 3, caracterise en ce que 
l'authentification est rtalisde par reconnaissance d'une clef facets transmise par le 
rEscau infonnatique du poste client au serveur de paiement. 

5. Precede scion Tune quelconque dcs revendications 1 £ 4, caracterise en 
35 ce qu'il comprend I'llaboration par le serveur de paiement d'un bon de caisse 
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comport ant au moins unc paitie dcs informations du ticket dc paiement ct unc 
information de certification. 

6. Precede selon Tune quelconque des revendications 1 a 5, caracterise en 
ce qu'il comprcnd la memorisation par le servcur de paiement des transactions 

5 autorisees, par stockage d'au moins une partie du contenu des bons de caisse. 

7. Precede selon Tune quelconque des revendications 1 a 6, caracterise en 
ce que le ticket de paiement est transmis du serveur du marchand au serveur de 
paiement par rinterm6diaire du poste client. 

8. Precede selon Tune quelconque des revendications 1 a 7, caracterise en 
10 ce que le bon de caisse est transmis du serveur de paiement au serveur du 

marchand par l'intermediaire du poste client. 

9. Systeme de paiement electronique pour effcctuer des transactions liees 
a l'achat de biens offerts par des marchands a des clients via un reseau informatique 
ouvert, le systeme comport ant des postes clients et des postes serveurs de 

15 marchands fwuv^ffe^ 

systeme caract£ris6 en ce qu'il comporte en outre au moins un poste serveur de 
paiement distinct des postes clients et serveurs de marchands et comprenant : 

- une unit6 frontale munie de moyens de connexion au r6seau ouvert, 

- une unit6 dorsale munie de moyens de connexion a un r€seau 
20 bancaire independant du reseau ouvert, 

- des moyens de communication cntrc les unites frontale et dorsale, 

- des moyens de memorisation de comptes de clients, de comptes de 
fournisseurs, et 

- des moyens de traitement pour, en riponse a la reception par l'unit6 
25 frontale d'une demande d'autorisation de transaction ou ticket de paiement, 

concemant un achat envisage entre un marchand et un client, verifier si le paiement 
du prix est autorise pour le client concern^ par interrogation du compte du client 
ou du reseau bancaire et, si la verification est positive, ilaborer unc autorisation de 
transaction, ou bon de caisse afin dc la transmettre sur le reseau ouvert via Tunit6 
30 frontale. 

10. Systeme de paiement selon la revendication 9, caractlrisl en ce que le 

serveur de paiement comprend des moyens de memorisation des transactions 
autorisees. 
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